System and method for specifying rules for operational systems

ABSTRACT

A method of controlling an operational system by a rules management system comprising a processor and a memory, and a computing apparatus comprising a processor and a memory are provided. The processor is programmed to execute rules from a rules repository stored on a memory in response to a request. The computing apparatus further comprises a high rules repository storing one or more high level rules, wherein each high level rule, when executed by the processor, modifies the effect of execution of one or more rules Rm in the rules repository; and a high rules conditions module that when executed by the processor identifies and executes the high level rules that apply to the request.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/156,488 filed Oct. 10, 2018, and claims priority to European PatentApplication No. 17197864.6, filed Oct. 23, 2017, all entitled “SYSTEMAND METHOD FOR SPECIFYING RULES FOR OPERATIONAL SYSTEMS”, the entiretiesof which is incorporated herein by reference.

FIELD OF INVENTION

The present invention relates to the management and execution of rulesfor operational systems. In specific aspects, it relates to methods andsystems for modifying the outcome of multiple rules.

BACKGROUND

A rule management system is a platform used to define, deploy, execute,monitor and maintain a variable and complex decision logic used byoperational systems. The rule management system allows the logic (alsoreferred to as rules) to be extracted and managed separately from otherparts of the operational system, allowing a user of the rule managementsystem to specify new rules without the need to modify each part of thesystem on which the new rule may have an effect.

Rule management systems may be used in a variety of contexts and areparticularly advantageous where the requirements of an operationalsystem are subject to a high degree or frequency of change, where thedecision used by the system is very complex, for example because itinvolves a large number of complex and interrelated requirements, orwhere consistency and traceability of actions or decisions made need tobe guaranteed across the operational system.

For example, rules and rules management system may be used in an accesscontrol system in an office facility, to manage multiple requirements ofthe system including who can open which door, when is each door/categoryof door locked, which identification is required before opening a door,etc. Using rules to define, modify and execute such requirements meansthat a facilities manager can easily define very granular requirements(e.g., where different areas of the facility are occupied by differenttenants, have different operational requirements, etc.) as well asconcurrently manage general requirements, without having to alter thecore applications present e.g., at each door or in each office suite.

However, when a user of the rules management system wishes to implementa change that relates to multiple existing rules, there is a significantoverhead involved in identifying, modifying and testing each of therelevant existing rules to implement the change.

SUMMARY

In accordance with a first aspect, the invention provides a method ofcontrolling an operational system by a rules management systemcomprising a processor programmed to execute rules from a rulesrepository stored on a memory. The method comprises providing one ormore high level rules comprising a condition part and an effect part,wherein each high level rule, when executed, modifies the effect of oneor more rules R_(m) in the rules repository; identifying the rules R_(m)that match the condition part of the high rule; and receiving a requestrelating to one or more rules and checking whether the one or more highlevel rules apply to the request; executing each rule R_(m) and/or eachhigh level rule that applies to the request.

In embodiments, the effect part of the high level rule is qualified asan “add” effect, and the high level rule modifies the effect of one ormore rules R_(m) by combining the effect of the rule with that of thehigh rule. In some embodiments, executing the rules that apply to therequest comprises executing each R_(m) and each high level rule.

In embodiments, the effect part of the high level rule is qualified as a“replace” effect, and a high level rule modifies the effect of one ormore rules R_(m) by replacing the effect of each rule R_(m) with that ofthe high rule. In some embodiments, executing the rules that apply tothe request comprises executing the high level rule only for each R_(m)identified.

Providing one or more high level rules may comprise a user defining highlevel rules at a rule management interface. In embodiments, defininghigh level rules comprises defining whether the action of the high levelrule is to replace or be combined with the actions of the rules R_(m).In embodiments, defining the high level rules comprises defining one ormore criteria to identify the rules R_(m) to modify.

The method may further comprise verifying the one or more high levelrules provides do not overlap or conflict with existing high levelrules.

In embodiments, the method further comprises recording a pointer to eachrule R_(m) that matches the condition part of each high rule, andrecording whether the effect part of the high level rule is qualified asan “add” effect or a “replace” effect.

In accordance with a second aspect, the invention provides a computingapparatus comprising a processor and a memory, wherein the processor isprogrammed to execute rules from a rules repository stored on a memoryin response to a request. The computing apparatus further comprises ahigh rules repository storing one or more high level rules, wherein eachhigh level rule, when executed by the processor, modifies the effect ofexecution of one or more rules R_(m) in the rules repository; and a highrules conditions module that when executed by the processor identifiesand executes the high level rules that apply to the request.

In embodiments, the computing apparatus further comprises a rulemanagement interface configured to allow a user to specify new highrules.

In embodiments, the computing apparatus comprises a high rules parserthat when executed by the processor: separates a high rule into anaction part and a condition part; and sends the action part to the highrules repository and the condition part together with a pointer to theaction part to the high rules condition module.

The computing apparatus may further comprise a sanity check module thatwhen executed by the processor determines whether a new high rulesatisfies one or more defined criteria by comparing the new high rule toexisting high rules and rules in the rules repository. In embodiments,the sanity check module when executed by the processor preventsdeployment of a new high rule that does not satisfy one or more of thedefined criteria.

Using the invention, it is possible to simply and efficiently modify theeffect of multiple rules in an operational system with a minimumoverhead in identifying, modifying and testing each of the relevantexisting rules to implement the change.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the invention will now be described, by way of exampleonly, with reference to the accompanying drawings, in which:

FIG. 1 illustrates schematically a rule management system according tothe prior art;

FIG. 2 illustrates a method of specifying high level rules according toan embodiment of the invention, as a flow diagram;

FIG. 3 illustrates schematically a rule management system according toan embodiment of the invention;

FIG. 4 illustrates a method of deploying high level rules according toan embodiment of the invention, as a flow diagram;

FIG. 5 is a flowchart showing a method of executing rules according toan embodiment of the invention;

FIG. 6 illustrates an exemplary implementation of an embodiment of theinvention applied to an access control system; and

FIG. 7 is a flowchart showing a method of executing rules for an accesscontrol system according to an embodiment of the invention.

DETAILED DESCRIPTION

A rule (also referred to as ‘business rule’ because they are frequentlyused to formalise aspects of the functioning of a business) is astatement that defines or constraints some aspect of the operationalsystem to which it relates. Rules are atomic in the sense that theycannot be broken down or decomposed further into more detailed rules.Rules are expressed in one or more formal rule statements. Formal rulestatements are simply expressions of rules in the convention of aparticular formal grammar (also referred to as ‘formal expressiontype’). Formal expression types include structured English, IDEF1X,Oracle's CASE*Method, Object Role Modelling, Ross's notation, etc.Formal rule statements are also referred to herein as ‘rules’ forreadability, and the skilled person would be able to interpret the termaccording to the context. Note, however, that in essence rules aresections of software which, when run on a suitable software platform,such as a rules engine, are responsive to an event or condition,determine a decision, and action or execute an outcome. This will becomeapparent in the discussion that now follows.

For example, a rule for an access control system may specify therequirement that the system does not allow a door to be opened even withappropriate identification on Sundays because security must be contactedbefore the door can be opened. A structured English example of a formalrule statement corresponding to this rule is:

IF open-door-request.day = Sunday THEN a. Halt ID-authorisation b. CallSecurity ENDIF

As another example, a rule for an online ordering portal for a foodvendor may specify the requirement that the system does not allow a userof the online ordering portal to order food via the portal on Sundaybecause the shop is closed. A structured English example of a formalrule statement corresponding to this rule is:

IF order.day = Sunday THEN a. Halt order b. Display message(“The shop isclosed on Sundays”) ENDIF

There are three main types of rules: structural assertions, actionassertions, and derivations. Structural assertions are terms (definedconcepts) or statements of fact that express some aspect of thestructure of an operational system, including facts assembled fromterms. Action assertions are statement of a constraint or condition thatlimits or controls the actions of an operational system (e.g., IF thisTHEN do that). Derivations are statements of knowledge derived fromother knowledge in the operational system. This disclosure is primarilyconcerned with rules that are action assertions, i.e., rules asexemplified above, that define what the behaviour of the operationalsystem (or parts thereof) should be in a given context, in response to agiven challenge, etc.

A user of the rules management system can simply specify rules torepresent constraints that should be applied to an operational system,via a rule management system. The rule management system can then deploythe rule dynamically, without needing to take any of the systems that itresponds to offline/out of service, because no change to the structureof any of the core applications of the operational system is required.In the example of the food vendor above, the user of the rulesmanagement system can simply use the system to set opening hours andbehaviours dynamically and define the required behaviour of any externalapplications (for example the online ordering portal, the securitysystem of the physical shop, the answering machine of the phone line ofthe shop, etc.) without having to modify the code of the coreapplications controlling each of these functions.

FIG. 1 illustrates schematically a simple rule management system 100.The system comprises a rules engine 102, a rule management interface104, and a data storage 106. The rule management interface 104 is usedby a user of the system 108 to write, modify and manage rules. The rulemanagement interface 104 is a programme that, when executed by aprocessor on a computing device, allows a user to write, modify andmanage rules. The computing device hosting the rule management interface104 typically comprises in addition to a processor, a memory storing theprogramme, and an input/output system to allow interaction with theuser. As the skilled person would understand, the computing devicehosting the rule management interface 104 may be a user computing deviceor may be provided by a server and accessed by the user 108 via a usercomputing device. The data storage 106 comprises a rules repository 106a and optionally one of more additional data stores 106 b. The optionaldata stores 106 b may be provided outside of the rule management system,or may be omitted entirely. The optional data stores 106 b may comprisedatabases that store information regarding requests that have beensubmitted, rules that have been executed, results that have beenobtained, information that may be used to interpret a request, etc. Therules engine 102 executes requests from an end user 108 or an externalapplication 110, using data from the data storage 106, and returns theresult of execution of rules to one or more external applications 110and/or end users 108 (for example, when external application 110comprises a user interface). The end user 108 may be the same person asthe user of the system (as illustrated on FIG. 1), or may be a differentperson, submitting requests to the rule management system that has beenpreviously set up by the user of the rule management system. As theperson skilled in the art would understand, requests may be submitted bya (physical) user and/or may be generated by other applications,devices, etc., that communicate with the rule management system in orderto obtain a decision, for example on which action should be performed ina given situation. In particular, the rules engine 102 comprises aprocessor 112 and a memory 114, storing algorithms that, when run by theprocessor, allow the rules engine 102 to identify the rules stored inthe rules repository 106 a that are applicable to a request, define anorder in which the rules should be executed, and execute the rules. Inembodiments, the rule management interface may be executed by the sameprocessor 112 and may optionally be stored on the same memory 114 as therules engine 102.

According to the invention, there is provided a new type of rules,referred to herein as ‘high level rules’ or ‘high rules’ (HR), and anassociated language and architecture. High rules allow a user to changethe output of multiple rules at a global level, without having tomodify, deploy and test each rule that may be impacted by the change.This results in a significant time saving, and reduces the number ofoperations needed to implement a change, thereby reducing the potentialfor errors.

FIG. 2 is a flowchart illustrating a method of specifying high levelrules according to an embodiment of the invention. At step 200 a user ofthe rules management system can specify one or more criteria thatindicate which rules should have a different output following thechange. In embodiments, the user may specify criteria that indirectlyindicate which rules should have a different output following thechange, for example by specifying one or more criteria on the content ofa request, wherein requests satisfying the criteria may satisfy thecondition statement of multiple rules. For example, a user may be ableto specify the criteria that the request mentions an open door request.This may correspond to indicating a series of rules where the conditionstatement contains “IF open-door-request”. In embodiments, a user of therules management system may want to modify the output of rules where thecondition matches or contains a given element. The user then specifies202 which command(s) (action(s)) should be executed when rules thatsatisfy the one or more criteria are executed. The user may then specify204 whether the command should replace the existing action part of therules concerned, or be executed in addition, i.e., whether the high ruleis a “replace” or an “add” rule. In embodiments, the system may have adefault option for this setting (e.g., “replace” or “add”) and the usermay omit step 204. At step 206 the rule is then deployed in the rulemanagement system (see below). Therefore, the high level rule can beconsidered to comprise a ‘condition’ part which serves to identify or‘match’ which lower level rules will be affected by the execution of thehigh level rule, and an ‘effect’ or ‘action’ part which defines thechange in the rule action that the high level rule is to carry out.

In the example above, a user of the rule management system for an accesscontrol system may want to change the behaviour of the access controlsystem on Saturdays, to specify that security should also be called onSaturday. The user will therefore specify at step 200 that rulesincluding “day=Saturday” in the condition part should be modified, atstep 202 that the action to include is “Call Security”, and at step 204that this action is to be executed in addition to what is normally doneon Saturday. The user may instead or in addition want to change the“Call Security” behaviour, regardless of the day and which conditiontriggered this action, because they no longer have security and insteadhave installed a keypad with a code on each door. The user can thereforespecify at step 200 that rules including “Call Security” in the actionpart should be modified, at step 202 that the action to include is“Request access-code”, and at step 204 that the action is to replace“Call Security”.

The deployment and execution phases in a rule management systemincluding high rules will now be explained in more detail. FIG. 3illustrates schematically a rule management system 300 according to anembodiment of the invention. The system described is a convenientembodiment implementing the high rules of the invention with a low levelof modification required from a conventional rules management system.However, the skilled person would understand that differentimplementations are possible, and in particular that functions indicatedas performed by some entities may in fact be performed by otherentities, such as existing entities of a rules management system.

The system comprises a rules engine 302, a rule management interface304, and a data storage 306. As is the case in the embodiment of FIG. 1,the rule management interface 304 is an algorithm executed by aprocessor and that enables a user 308 of the rules management system towrite, modify, and manage rules. However, the rule management interface304 comprises a rules module 304 a and a high rules module 304 b,allowing the user to write, modify and manage rules and high rules,respectively. The rules engine 302 is similar to the rules engine 102above and performs a similar function. In particular, the rules enginealso comprises a processor 312 and a memory 314, storing algorithmsthat, when run by the processor, allow the rules engine to identify therules that are applicable to a request, define an order in which therules should be executed, and execute the rules. The processor 312 andmemory 314 may also execute and store the rule management interface 204algorithm, or these may be functions may be provided by a separateprocessor and/or memory of a server or user computing device. The datastorage 306 comprises a rules repository 306 a, a high rules repository306 c and optionally one of more additional data stores 306 b. The rulesrepository 306 a and optional data stores 306 b are similar in structureand function to those above.

The system additionally comprises a high rules parser 316. The high ruleparser 316 is an algorithm stored on a memory and executed by aprocessor. The memory and/or processor may be the same as processor 312and memory 314, or may be provided separately. In the deployment phaseillustrated in the flowchart of FIG. 4 (i.e. after a user of the rulesmanagement system has specified one or more new high rules, for exampleas explained in relation to FIG. 2, using the high rule module 304 b ofthe rule management interface 304), the high rules parser 316 receives400 a high rule from the rule management interface 304 and separates 402it into its condition and its action part. The high rules parser 316sends 404 the action part to be stored in the data storage 306, inparticular in the high rules repository 306 c. As the skilled personwould understand, the rules and high rules repository need not beseparate storages and may instead be a single data repository. In theseembodiments, the action part of high rules may be stored in a similarway as normal rules but without requiring a condition part. The highrules parser 316 then sends 406 the condition part to the high rulescondition module 318, which queries 408 the rules repository 306 a toidentify the rules in the rules repository 306 a that match the criteriaspecified by the user for the high rule (see step 200 above). The highrules conditions module 318 then records 410 a pointer to each of thematching rules together with the condition part of the high rule. Thehigh rules conditions module 318 records a pointer to the correspondingaction part in the high rules repository 306 b, and the information asto whether the high rule is an “add” or a “replace” rule, received fromthe high rules parser 316 at step 406. The high rule condition module318 comprises an algorithm that is stored on a memory and executed by aprocessor, and a data storage 320 that stores the high rules conditionsand pointers. The memory and/or processor may be the same as processor312 and memory 314, or may be provided separately. The data storage 320may instead be part of the data storage 306. The functionality of thehigh rule condition module 318 is further explained below.

The process of matching the conditions of a high rule to existing rulesin the rules repository 306 a, and recording pointers to matched rules,is performed whenever a new high rule is specified. In embodiments, thisprocess is also performed whenever a normal rule in the rules repository306 a is expired or changed.

In embodiments, a rule validation module 318 a may be provided whichchecks that the matching of the condition part of the high rules to thecontent of the rules repository 306 a satisfies some criteria. While therule validation module 318 a is shown here as part of the high rulescondition module 318, the skilled person would understand that this canalso be a separate module that communicates with the high rulescondition module 318 and optionally the rule management interface 304.In embodiment, the rule validation module 318 a verifies that the highrule specified satisfies at least the condition that one or morematching rules were identified by the high rules condition module 318.In embodiments, the rule validation module 318 a checks whetheroverlapping or contradicting high rules have been created. For example,the rule validation module 318 a may identify whether multiple highrules apply to the same or overlapping conditional statements but atleast one of these high rules is a “replace” rule. In embodiments, therule validation module 318 a may verify that the condition part of thehigh rule satisfies a specified maximum level of granularity, i.e., thatthe condition part specifies criteria that contain a specified minimumlevel or information. This may help to keep the number of matching rulesto a level that is considered appropriate. For example, a high rulecondition such as “contains open-door-request” may be considered to beat too high level of granularity whereas a condition such as “containsopen-door-request.dayX” where dayX is a specified day of the week may beconsidered to be of sufficiently low granularity. The rule validationmodule 318 a may send an error or a warning message to the rulesmanagement interface 304 directly or via the high rules condition module318 if one or more of the specified criteria are not satisfied. Instead,or in addition to sending an error message, the rule validation module318 a may prevent a high rule from being deployed if one or more of thespecified criteria are not satisfied. In embodiments, the rulevalidation module 318 a may produce an error message and/or prevent ahigh rule from being deployed if its condition part fully overlaps withan existing high rule. In embodiments, the rule validation module 318 amay produce a different output when the condition part of a high rulepartially overlaps with one or more existing high rules, depending onthe logical construction of the partially overlapping high rules. Forexample, the rule validation module 318 a may prevent deployment of ahigh rule that defines multiple conditions combined with a logical “OR”(i.e., defining alternative conditions) if a high rule with a conditionmatching any of the multiple alternative conditions of the new rulealready exists. However, the rule validation module 318 a may notprevent deployment of a high rule that defines multiple conditionscombined with a logical “AND” (i.e., defining at least two requiredconditions) provided that no high rule already exists that has the samecombination of required conditions. In such cases, the rule validationmodule 318 a may send a warning/error message to inform the user of thepotential conflict.

FIG. 5 is a flowchart showing a method of executing rules according toan embodiment of the invention. At step 500 an end user or externalapplication submits a request. In this case, requests are not sentdirectly to the rules engine 302, but are instead sent 502 to the highrule conditions module 316 (HRCM), optionally via a high rule front end(not shown). The HRCM 316 then checks 504 whether any high rules can beexecuted on the request (i.e., whether the data in the request fallsunder any of the conditions (IF parts) associated with high rules). Ifthere are no high rules applicable to the request, the high rulesconditions module sends 506 the request to the rules engine 302, whichprocesses 508 the request in a conventional way.

However, if there is a high rule that can act on the request, the highrule conditions module 318 checks 510 whether the high rule is an ‘add’or a ‘replace’ high rule. If the high rule is an ‘add’ rule, the HRCMsends 512 the request to the rules engine. However, instead of executingall of the rules that apply to the request, the rules engine executes514 each rule R_(m) that matches the condition to be modified by thehigh rule (using the pointers recorded by the high rules conditionsmodule 318 at step 410), then sends 516 the result to the HRCM, whichexecutes 518 the action part of the high rule. When all of the rulesthat apply to the request have been executed by the rules engine and thehigh rule action part added, the HRCM outputs 520 the result of the ruleexecution process. If the high rule is a ‘replace’ rule, the HRCM alsosends 512′ the request to the rules engine. However, the rules enginethen identifies 514′ each rule R_(m) that applies (using the pointersrecorded by the high rules conditions module 318 at step 410), but doesnot execute it the action part of each of these rules. Instead, aftereach of these rules it contacts 516′ the HRCM where the action part ofthe high rule is executed 518′. When all rules that apply have beenidentified and the high rules actions executed, the HRCM outputs 520 theresult of the rule execution process.

In embodiments, the high rules conditions module 318 may define an orderin which high rules are executed when step 504 above identifies thatmultiple high rules apply to the request. For example, the high rulescondition module 318 may execute rules that are logically simple beforerules that are logically more complex. In this context, a rule may beconsidered to be logically simpler (i.e., less complex) when itcomprises fewer elements in the conditional statement. For example, arule such as “contains open-door-request” is logically simpler than arule such as “contains open-door-request AND contains location=safe”.

In embodiments (not shown), step 510 may be omitted and the request sent512 to the rules engine regardless of whether the high rule is an ‘add’or a ‘replace’ rule. In such embodiments, the rules engine may execute514 each rule R_(m) and send the result to the HRCM. At this stage, theHRCM can check whether the high rule is an “add” or a “replace” andexecute 518 the action part accordingly.

The present invention will now be illustrated by reference to an accesscontrol system, for example a system to control physical access ofauthorised personnel to a facility. However, the person skilled in theart would understand that the teaching of the invention is applicable toa variety of industries, including, amongst others:

health care and life sciences: clinical decision support, druginteraction assessment, clinical trials data validation, etc.;

banking: fraud prevention, credit risk decisions, payment feecalculations, cross-sell offer management, etc.;

insurance: policy underwriting claims processing, risk rating,commission calculations, etc.;

manufacturing: order configuration validation, order prioritisation,etc.;

public sector: services entitlement and benefits calculations, tax fraudassessment, border control and security screening, etc.;

retail: online recommendations, pricing and tax calculations, loyaltyprogram offer management, etc.

FIG. 6 shows an access control system comprising a rule managementsystem according to an embodiment of the invention. An access controlsystem may be installed in a facility with multiple zones and multipleaccess points. The access control system may comprise one or morelocking systems, and each locking system may comprise one or moreidentification modules. Identification modules may comprise systemsusing codes, physical keys, identification card, biometrics, humanintervention (e.g., intercom), etc., or combinations thereof. In theexample on FIG. 6, a facility 600 with multiple zones 602-612 and accesspoints 614-628, is equipped with locking systems (not shown) at some orall access points. The access control system comprises an access rulemanagement system, which communicates with the locking systems (wherethe locking systems are external applications 110, 310). The access rulemanagement system 630 interfaces with the locking systems to execute adecision logic comprising the following rules:

Rule A:

If open door request and door is internalthenrequest card identification

Rule B:

If open door request and time is between 8 pm and 8 amthenrequest card identification

Rule C:

If open door request and door is externalthenrequest access code

Rule D:

If all identification verifiedthenopen door

In particular, a locking system (i.e., external application) may receivedata in the form of an “open door request”, for example following aperson at the door pressing an “open” button associated with the lockingsystem, or a sensor detecting the presence of a person at the door. Thelocking system may then communicate this data to the access rulesmanagement system 630 in order to obtain the appropriate action to beperformed. The access rule management system 630 evaluates the dataagainst the rules stored in its database, and decides which rule(s) needto be executed. The access rule management system 630 then outputs theresult of the rule execution to the locking system (i.e., in this casethe locking system is also the output application), and the lockingsystem may perform the appropriate action (e.g., request identification,or request access code).

Suppose a user of the rules management system associated with the accesscontrol system needs to implement a new requirement of the accesscontrol system, for example that a biometric measurement must be takenbefore opening any door. Then using the system of the invention, insteadof separately changing each of rules A, B and C, the user will be ableto write a single rule:

HR1:

In facility ywhere mentioned “If open door request”addrequest biometric measurement

FIG. 7 is a flowchart showing a method of executing rules for an accesscontrol system according to an embodiment of the invention. Whenever anexternal application, in this case a locking system, sends 700 inputdata (also referred to as “request”) to the rule management system 630indicating one or more variables, in this case “open door request, door616, facility y, 5 pm”, the data is passed 702 to the high level rulemodule. The high level rule conditions module of the high level rulemodule checks 704 whether any high level rule conditions apply to theinput data. In this case the high level rule parser would haveidentified that the conditional statements of rules A, B and C satisfythe required criteria, and there are therefore rules R_(m) whosebehaviour should be modified by HR1. If none of the high level ruleconditions apply to the input data, the request is communicated 706 tothe rules execution engine which executes 708 the normal rules andproduces 720 the output to the output application, in this case thelocking system. In this case, HR1 is identified as applicable to theinput data, and any rule R_(m) that is executed should be modified byHR1. The high level rule conditions module checks 710 whether HR1 istagged as an “add” or a “replace” rule. In this case HR1 is tagged as an“add” high rule. Therefore, the high rules conditions module passes 712the control (i.e. send the request) to the rule execution engine whichidentifies a first rule R_(m) ¹ (using the pointers recorded by the highrules conditions module 318 at step 410) that is applicable and executes714 it (e.g. in this case rule A is applicable, if the time had beenbetween 8 pm and 8 am then rule B would also have been applicable), thenpasses 716 the control back to the high rule conditions module. The highrule condition module then executes 718 the action part of HR1, andpasses the control back to the rules execution engine to execute thenext identified rule R_(m) ² that applies to the input data. The actionpart of HR1 is then executed, and this cycle continues until all rulesthat are applicable (i.e., all rules where the condition part matchesthe input data) have been executed. The high rule conditions module thensends 720 the output (i.e., the actions) to the output application,i.e., the locking system. The locking system will then be able toimplement the desired action, i.e.: request card identification, requestbiometric measurement (i.e., Rules A and HR1).

Suppose now that the user of the rules management system associated withthe access control system needs to implement a new requirement of theaccess control system, for example that the biometric measurement betaken before opening any door, and that the biometric measurement issufficient identification. Then using the system of the invention,instead of separately changing each of rules A, B and C, the user willbe able to write a single rule:

HR2:

In facility ywhere mentioned “If open door request”replacerequest biometric measurement

In this case, the high level rule conditions module of the high levelrule module will identify 704 that the conditions of HR2 apply to theinput data, and that HR2 is a “replace” rule 710. In this case, the highrule conditions module will pass 712′ the control (i.e. send therequest) to the rule execution engine but upon each rule match 714′(i.e. for each rule i that the rule engine identifies as applicableusing the pointers recorded by the high rules conditions module 318 atstep 410), instead of executing the rule, the rule execution engine willpass 716′ the control back to the high rule conditions module which willexecute 718′ the action part of HR2. The cycle continues until all ofthe rules with a condition that matches the input data have beenexecuted, following which the high rule conditions module communicates720 the output (i.e., actions) to the output application. The lockingsystem will then be able to implement the desired action, i.e.: requestbiometric measurement (i.e., Rule A and HR2).

Although the invention has been described with reference to a number ofspecific embodiments, the skilled person will appreciate that theinvention may be embodied in many other forms.

What is claimed is:
 1. A method of controlling a fraud prevention system by a rules management system comprising a memory storing instructions executed by a processor, the method comprising: providing, by the processor, one or more high level rules comprising a condition part and an effect part, wherein each of the high level rules, when executed, modifies the effect part of one or more rules in a rules repository stored in the memory; validating, by a rule validation module implemented on the processor, that the one or more rules match the condition part of the one or more high level rules; receiving, by a high rule conditions module implemented on the processor, a request to execute the one or more rules; determining, by the high rule conditions module, the one or more high level rules apply to the request; in response to determining the one or more high level rules apply to the request, identifying, by the rule validation module, one or more criteria indicating the one or more high level rules are not satisfied; and in response to identifying the one or more criteria are not satisfied, preventing fraud at least by preventing the one or more high level rules from being deployed.
 2. The method of claim 1, further comprising: transmitting, by the rule validation module, a warning message to a rules management interface.
 3. The method of claim 2, wherein the preventing the one or more high level rules from being deployed and the transmitting the warning message collectively comprise a fraud prevention operation.
 4. The method of claim 1, wherein: the identified one or more criteria indicate the condition part, to be satisfied, of the one or more high level rules, and identifying the one or more criteria are not satisfied comprises determining the condition part of the one or more high level rules is not satisfied.
 5. The method of claim 1, wherein preventing the one or more high level rules from being deployed comprises declining to execute the effect part of the one or more high level rules.
 6. The method of claim 1, further comprising verifying the provided one or more high level rules do not overlap or conflict with existing high level rules based on one high level rule of the one or more high level rules defining at least two required conditions, wherein no other high level rule of the one or more high level rules includes the defined at least two required conditions.
 7. The method of claim 1, further comprising: separating, by a rules parser, a high level rule of the one or more high level rules into the condition part and the effect part, and sending, by the rules parser, the effect part to the rules repository and the condition part to the high rules condition module.
 8. A computing apparatus for controlling a fraud prevention system by a rules management system, the computing apparatus comprising: a processor; a memory storing a rules repository, wherein the rules repository stores one or more high level rules comprising a condition part and an effect part, wherein each high level rule, when executed, modifies the effect part of one or more rules in the rules repository; a rule validation module, implemented on the processor, configured to validate the one or more rules match the condition part of the one or more high level rules; and a high rule conditions module, implemented on the processor, configured to: receive a request to execute the one or more rules, and determine the one or more high level rules apply to the request, wherein the rule validation module is further configured to: in response to the determination the one or more high level rules apply to the request, identify one or more criteria indicating the one or more high level rules are not satisfied; and in response to the identification the one or more criteria are not satisfied, prevent fraud at least by preventing the one or more high level rules from being deployed.
 9. The computing apparatus of claim 8, wherein the rule validation module is further configured to: transmit a warning message to a rules management interface.
 10. The computing apparatus of claim 9, wherein the preventing the one or more high level rules from being deployed and the transmitting the warning message collectively comprise a fraud prevention operation.
 11. The computing apparatus of claim 8, wherein: the identified one or more criteria indicate the condition part, to be satisfied, of the one or more high level rules, and to identify the one or more criteria are not satisfied, the rule validation module is further configured to determine the condition part of the one or more high level rules are not satisfied.
 12. The computing apparatus of claim 8, wherein, to prevent the one or more high level rules from being deployed, the rule validation module is further configured to decline to execute the effect part of the one or more high level rules.
 13. The computing apparatus of claim 8, wherein: the rule validation module is further configured to verify the provided one or more high level rules do not overlap or conflict with existing high level rules based on one high level rule of the one or more high level rules defining at least two required conditions, and no other high level rule of the one or more high level rules includes the defined at least two required conditions.
 14. The computing apparatus of claim 8, further comprising a rules parser configured to: separate a high level rule of the one or more high level rules into the condition part and the effect part, and send the effect part to the rules repository and the condition part to the high rules condition module.
 15. A rules management system for controlling a fraud prevention system by a rules management system, the system comprising: a processor; and a memory comprising a rules repository, wherein the rules repository stores one or more high level rules comprising a condition part and an effect part, wherein each high level rule, when executed, modifies the effect part of one or more rules in the rules repository, wherein the memory further comprises instructions that, when executed by the processor, cause the processor to: validate the one or more rules match the condition part of the one or more high level rules, receive a request to execute the one or more rules, determine the one or more high level rules apply to the request, in response to the determination the one or more high level rules apply to the request, identify one or more criteria indicating the one or more high level rules are not satisfied, and in response to the identification the one or more criteria are not satisfied, prevent fraud at least by preventing the one or more high level rules from being deployed.
 16. The rules management system of claim 15, wherein the processor is further configured to: transmit a warning message to a rules management interface, wherein the preventing the one or more high level rules from being deployed and the transmitting the warning message collectively comprise a fraud prevention operation.
 17. The rules management system of claim 15, wherein: the identified one or more criteria indicate the condition part, to be satisfied, of the one or more high level rules, and to identify the one or more criteria are not satisfied, the processor is further configured to determine the condition part of the one or more high level rules is not satisfied.
 18. The rules management system of claim 15, wherein, to prevent the one or more high level rules from being deployed, the processor is further configured to decline to execute the effect part of the one or more high level rules.
 19. The rules management system of claim 15, wherein: the processor is further configured to verify the provided one or more high level rules do not overlap or conflict with existing high level rules based on one high level rule of the one or more high level rules defining at least two required conditions, and no other high level rule of the one or more high level rules includes the defined at least two required conditions.
 20. The rules management system of claim 15, wherein the processor is further configured to: separate a high level rule of the one or more high level rules into the condition part and the effect part. 